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'5 APOLLO NETWORK k 

G Carlo. Roberts, Jr. ^ 


Mr. Roberts is Head of the Manned Flight Systems 
Engineering Section (MFOD) . He is responsible for 
systems design, engineering, equipment specifica- 
tions , and network qualification of the Manned Space 
Flight Network for Gemini, Apollo, and other manned 
programs. Formerly he headed up the Bendix Radio 
Engineering Support Group at Goddard. 


Although the design of the Apollo network followed closely behind the Manned 
Space Flight Network (MSFN) modification for the Gemini program, many site 
modifications were necessary to provide Apollo support due to the greater scope 
of the Apollo program. The Apollo program requires instrumentation for sup- 
port of the S-I, S-II, S IV-B/IU, Command Service Module (CSM) and Lunar Ex- 
cursion Module (LEM) stages. Support must also be provided at both orbital 
and lunar distances. Increased data processing capability is required for pro- 
cessing and displaying significantly larger amounts of information. The ground 
network requires the capability of processing both Pulse Code Modulation (PCM) 
telemetry and command data for the CSM, LEM, and S IV-B/IU. In various 
stages of the Apollo program, both tone (on UHF) and digital [on Unified S-Band 
(USB) and UHF] command capabilities are required. Also at various stages 
both USB and VHF telemetry links are required. 

To provide support for the Apollo program many significant changes were 
made to the network data systems: 

1. The Unified S-Band System, built by Collins Radio of Dallas, Texas, 
combines the functions of acquisition, telemetry, command, voice and 
tracking on one RF link. The use of this system increases the data pro- 
cessing task, but reduces the number of required antenna mounts, trans- 
mitters, receivers, etc. This system also includes receiving and rang- 
ing equipment designed by the Jet Propulsion Laboratory (JPL) to supply 
range and range rate information. 

2. Stored program PCM telemetry decommutators were specified for the 
Apollo installations to provide increased data handling capability and 
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more flexibility. This system is presently being delivered by Dynatronics 
of Orlando, Florida. 

3. Computer-driven alpha numeric displays, built by Raytheon of Way land, 
Massachusetts, were selected to provide a greater and more versatile 
capability to the on-site flight controllers. This system permits the dis- 
play of printed information and charts of real time data on a cathode ray 
tube. 

4. A general purpose data processing system utilizing 642 B modified com- 
puters, manufactured by Univac of St. Paul, Minnesota, is being supplied 
at each site to drive displays (where required), process telemetry, com- 
mand and teletype data and to select and format data for transmission to 
the Manned Spacecraft Control Center (MCC-H) at Houston. This system 
processes and stores command data received from MCC-H for delayed 
transmission to the Spacecraft. The data processing system at each site 
is also connected to MCC-H and Goddard by high speed data circuits. 

This feature provides MCC-H with the capability of remotely changing 
data parameters being transmitted to the Control Center and the capabil- 
ity of remotely uplinking data to the spacecraft. Additionally, it provides 
GSFC with the capability of automated check-out of the network, in detail, 
in real time. 

5. Other miscellaneous data systems are being added to the MSFN for Apollo 
support. These include TV monitors and scan converters, high speed 
printers, stored program PCM simulators, VHF predetection diversity 
combining receivers, and wide band recorders. 

Maximum flexibility, through modularity of design, and high reliability, 
through selected redundancy and use of solid state circuitry, were considered 
as important factors in the design of the network equipment. 

Redundant capability has been provided in the Data Processing System for 
reliability. Two identical computers have been provided for processing com- 
mand and telemetry data. An emergency program is being prepared which will 
enable one computer to process the most essential data for both command and 
telemetry functions. 

Expansion and reconfiguration capabilities have been designed into the major 
equipments. Most modifications which will be required to the MSFN from mis- 
sion to mission can be made by software change rather than hardware modifica- 
tions. Programmable units include the 642 B computers, PCM decommutators 
and simulators, the console computer interface adapter, and the display system. 
The flexibility which has been designed into the network systems should enable 
the MSFN to support a great variety of missions in the future. 
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l UNIFIED S-BAND SYSTEM G 

v W. Paul Varson f 


Mr. Varson, Head of the Manned Flight Support Office 
(MFSO) , has been in the missile and space program 
since 1951. As Head of the Technical Staff of the 
MFSO, he is responsible for the Unified S-Band pro- 
gram and coordination of the efforts of the Jet Propul- 
sion Laboratory in support of this program. 


The Apollo program is significantly more complex than either the Mercury 
or Gemini programs and has consequently presented a corresponding increase in 
the complexity of the support required from the Manned Space Flight Network 
(MSFN). For the first time, the network is required to provide tracking and 
communications to lunar distance which requires incorporation of the unified 
S-band (USB) system into the network. The existing network is capable of sup- 
porting the earth-orbital phases of the mission and will be used for support of 
the initial Apollo flights while the USB systems are being checked out for the 
lunar missions. 

The USB system utilizes a single carrier frequency in each direction to pro- 
vide tracking as well as communications with the spacecraft. The interface with 
the network equipment is the same whether the data comes from the USB system 
or the Gemini equipment. The unified systems approach was adopted rather 
than extending the range of the existing network equipment primarily because it 
was considered to offer a superior technical solution with a minimum of new 
development. There have been several approaches to the unified systems con- 
cept, but perhaps the most thoroughly developed is that used by the Jet Propul- 
sion Laboratory. This system has been employed successfully in support of 
lunar and planetary programs and, with minor modifications, was applicable to 
the Apollo tracking and communications requirements. 

The design of the USB system is based on a coherent doppler and the pseudo- 
random range system which has been developed by JPL. A single carrier fre- 
quency is utilized in each direction for the transmission of all tracking and com- 
munications data between the spacecraft and ground. The voice and up-date 
data are modulated onto subcarriers and then combined with the ranging data. 
This composite information is used to phase-modulate the transmitted carrier 
frequency . 
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In the transponder the subcarriers are extracted from the RF carrier and 
detected to produce the voice and command information. The binary ranging 
signals, modulated directly onto the carrier, are detected by the wide-band 
detector and translated to a video signal. 

The voice and telemetry data to be transmitted from the spacecraft are mod- 
ulated onto subcarriers, combined with the video ranging signals, and used to 
phase-modulate the down-link carrier frequency. The received and transmitted 
carrier frequencies are coherently related which allows measurements of the 
carrier doppler frequency by the ground station for determination of the radial 
velocity of the spacecraft. The transponder transmitter can also be frequency- 
modulated for the transmission of television information or recorded data in- 
stead of ranging signals. 

The basic USB system has the ability to provide tracking and communications 
data for two spacecraft simultaneously, provided they are within the beamwidth 
of the single antenna. The primary mode of tracking and communications is 
through the use of the PM mode of operation. In addition to the primary mode 
of communications, the USB system has the capability of receiving data on two 
other frequencies for the transmission of FM data from the spacecraft. 

The tracking and communications with the spacecraft during the lunar mis- 
sions will be provided by three primary deep-space facilities, employing 85-foot 
antennas, spaced at approximately equal intervals of longitude around the earth 
to provide the continuous coverage of the lunar missions. Three of the JPL 
Deep-Space Instrumentation Facilities (DSIF) located at approximately the same 
locations will be equipped to also support the lunar missions. Each of these 
facilities , both the primary and backup stations , will be equipped to track and 
provide communications with both the Lunar Excursion Module (LEM) and the 
Command Module simultaneously. 

In addition to the 85-foot stations, a number of other stations employing 30- 
foot antennas are also required in the network. These systems are needed for 
launch coverage, in-flight checkout of the spacecraft, to fill gaps in the coverage 
of the three lunar stations, and to provide instrumentation coverage for testing 
the spacecraft in earth orbit. 

Four land stations (Cape Kennedy, Grand Bahama, Antigua, and Bermuda) 
and one instrumentation ship are required to provide continuous USB coverage 
from launch through insertion. Seven land stations [Canary Islands (planned), 
Guaymas, Texas, Ascension Island, Carnarvon, Guam, and Hawaii] and two 
additional instrumentation ships are required to complete the USB system cov- 
erage requirements. In addition to these stations, the Apollo networks will also 
include two reentry ships and eight instrumented aircraft. 
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The USB system will be installed in the network during the next year. It 
will be checked out on the SA-202 through SA-206 and on SA-501 and SA-502 
missions and will be used to provide primary mission support data beginning 
with SA-207 and SA-503. 
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APOLLO REMOTE SITE 
DATA PROCESSOR SYSTEM C 

{ William E. Willis, Jr. 7^ 


Mr. Willis is computer system engineer in the 
Manned Flight Systems Engineering Section (MFOD) . 
He is responsible for computer systems design, engi- 
neering and specifications. Formerly, he headed the 
CADFISS (Computation and Data Flow Integrated Sub- 
systems Tests) effort at Goddard and was instrumen- 
tal in introducing computers and their use into the 
manned space tracking network. Mr. Willis has been 
working at Goddard since November 1959. 


The data processing system presently being installed on the Maimed Space 
Flight Tracking Network is one of the most complex of its kind ever attempted 
within the manned space flight effort. 

The data processing system selected for the Apollo remote sites is being 
manufactured and assembled by the UNTVAC Military System, Division of the 
Sperry Rand Corporation, located in St. Paul, Minnesota. The computer is 
identified as the UNIVAC 642 B Modified and has been designed to meet military 
specification. There will be two identical computing subsystems installed on 
each of the sites of the Apollo Tracking Network. These subsystems are iden- 
tical in every respect with the exception of the mission requirements which will 
be assigned to each subsystem. One computer subsystem will be used for the 
processing of telemetry data and will also provide a command processing back- 
up capability. The second computer subsystem will be used for the processing 
of command data and will also provide a telemetry processing back-up capabil- 
ity. The purpose of the back-up capability is to provide continuous operation for 
the remote site computing requirements should either computer malfunction 
during a critical period of the mission. 


DIGITAL COMMAND COMPUTER 

The purpose of the Apollo Command Computer is to provide a means for 
communicating with and controlling the spacecraft equipment from the ground. 
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Commands and command loads will be transmitted from the mission control 
center (MCC-H) over high speed data lines (2.4kbs) to the command computer 
located on any one or all of the remote sites. The computer will perform error 
checking functions on the received data as the data is stored in the command 
computer memory. It will also be outputted from the computer to the digital 
magnetic tape recording unit for storage and possible future use. Retransmis- 
sion from the mission control center (MCC-H) of all or any part of the message 
can be accomplished to update the command requirements stored in the computer 
memory should a change be required. Indications of a command load or a spe- 
cial command having been received by the computer on the remote sites will be 
provided to the computer operators and the flight controllers by way of a hard 
copy print-out. 

Every effort is made to insure that the commands generated at the mission 
control center are transmitted correct to the remote site and from the remote 
site to the orbiting spacecraft. 

Two command validation loops are available from the remote site computer 
to the orbiting spacecraft. One loop will sample the command throughout the 
monitor receiver for comparison in the computer. The other validation loop 
consists of message acceptance pulse data or any other special parameter from 
the spacecraft telemetry bit stream through the PCM system to the computer. 

Diagnostic program routines may be utilized in real time by the computer to 
check the status of the command transmitting systems and the ground validation 
loops during times of no command transmissions. This feature will greatly in- 
crease the level of confidence in the peripheral systems in that the malfunctions 
will be detected very rapidly. 


TELEMETRY COMPUTING SYSTEM 

The telemetry computing system will initially interface with three (3) Pulse- 
Code -Modulation (PCM) decommutation ground stations. Data inputted to the 
computer will be derived from the PCM telemetry serial bit stream after being 
processed through the PCM system. All data transfers between the PCM ground 
stations and the computer will be parallel, word size will be determined by mis- 
sion configuration, spacecraft telemetry systems or computer program. Each 
PCM data will be inputted to a separate input channel of the computer and all in- 
puts may occur at different rates. All data inputted to the computer from the 
PCM stations will be buffered and formatted for various types of requests is- 
sued to the computer, i.e. , 
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a. Summary message generation and transmission to the mission control 
center, Houston, Texas. 

b. Display request to the memory character generator memory for further 
display on the twelve (12) cathode ray tube displays located on the flight 
controller consoles. 

c. * Command history and command transmission to the spacecraft. 

d. Command transmission and verification should a failure occur in the 
command computer. 

Each remote site computing system will comprise the following listed 
equipments: 

a. 2 each 642 B Modified Computers , each having 16 input and 16 output 
channels and a 2 micro second read/write cycle. 

b. 2 each 1232 Input/Output Consoles which are used to communicate with 
the computer by a Keyboard, reader, or a paper tape punch. 

c. 2 each 1259 Teletype Systems , to receive or transmit low speed teletype 
data (100/60 wpm). 

d. 4 each 2010 Data Transmission Units , to receive or transmit high speed 
data (2.4kbs). 

e. 2 each 1299 Distribution Switch Panel , to switch data from one computer 
to the other depending on mission requirements. 

f . 2 each 1540 Digital Magnetic Tape Recorder /Reproducer Units , with bit 
packing densities of 200, 556 or 800 frames per inch. Each unit will be 
duplexed to both computers. 

g. 1 each Model 1000 Interface Systems Adapter , which contains five multi- 
plexed inputs to one computer channel. This will provide the flight con- 
trollers with the capability of communicating with the computer. 

Contained in the same cabinet will be the time buffer which is used to in- 
put GMT into both the computers at a rate of once per second. This time 
data will be used for computer documentation. All messages received 
or transmitted by the computer must be time tagged for later reference. 
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h. 1 each Console Computer Interface Adapter (CCIA) . This unit will pro- 
vide the means of communications between the seven flight control con- 
soles and the telemetry and command computers. The CCIA consists 
of two identical sections which are independent in all respects excluding 
their source of power. One section will service four consoles and the 
second section will service three consoles. 

To complete the system the computers are also interfaced with the unified 
S-Band up-data buffer for transmission of commands and the PCM simulator 
for closed loop tests. 
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'b APOLLO DISPLAY SYSTEM C 

{r Keith D. Fe Herman-^ 


Mr. Fellerman is the Technical Officer for the Apollo 
Display System. Prior to joining Goddard in April 
1964, he worked on radar and data processing for the 
Westinghouse Electric Company. He was an Elec- 
tronics Officer in the U. S, Air Force for four years 
after graduating from the U. S. Naval Academy in 
June 1952. 


The Apollo Display System now being installed at the Flight Controller sta- 
tions of the Manned Space Flight Tracking Network is a step forward in the sci- 
ence of displaying data. 

The Display System for Apollo is being designed and fabricated by Raytheon 
Company at their Wayland and North Dighton, Massachusetts plants. The system 
has been designated Digital Display System AM 102. 

The Display System serves as an interface between flight controllers and 
the high speed data processing equipment such as the telemetry and command 
computers and the Pulse Code Modulated (PCM) Data Handling Equipment. 

There are seven operator consoles (six on a land station) and four cabinets 
of electronics equipment called the Memory and Character Generator in each 
system. Each of the consoles has one or two cathode ray tube displays which 
can display alpha-numeric characters in two sizes and vectors. The Flight Con- 
troller may control the display format presented on his cathode ray tube (CRT) 
by use of the display request keyboard. The keyboard may request as many as 
50 different display formats. In addition, each display request keyboard is pro- 
vided with two overlays, doubling the number of switch functions provided. The 
identity for the overlay to the computer is provided by four coding switches. 
Overlays may be transferred from console to console. 

The displays may be updated with new data twice a second. The system is 
capable of more than this but to prevent flashing the rate is held down. 

The 642 B computer loads the memory in the Memory Character Generator 
(MCG) on 30 parallel lines. The words are transferred from the computer until 
a complete message is loaded. 
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The memory in each of the Memory Character Generators has a capacity of 
4096 18 bit words. This is divided into two 4096 9 bit word halves which serve 
two Character and Vector Generators. The memory halves are divided once 
more by use of a command word from the computer. Each display has a section 
of memory assigned to it since one Character Vector Generator serves two dis- 
plays and there are two Character Vector Generators (CVG) per MCG channel. 
The two displays served by each Character Vector Generator are in different 
consoles so that failure of a CVG would not cause a total console failure in any 
of the five consoles having two displays. 

The Character Vector Generator decodes the digital words into the analog 
voltages to form letters, numerals and vectors. The position information for 
the electron beam is transferred through the CVG as a 9 bit word. 

The displays are unique in that there is the ability to write on any part of 
the CRT with direct access to the particular X and Y coordinates that the char- 
acter or vector are to appear at, rather than a sweeping of the entire tube. The 
CR tube viewing surface is a 10 inch by 10 inch square. On this square, there 
is room for 18 lines of large characters of approximately 0.28 inches high and 
36 lines of small characters of 0. 14 inches in height. In each line, there may be 
a maximum number of 36 large or 72 small characters. The size of vectors 
line segments may be varied between 0.02 inches and 0.5 inches. 

The characters are drawn on the face of the CRT by the electrostatic deflec- 
tion slates using the analog voltages from the CVG. The beam is positioned to 
the proper area in which a character will be written by the electromagnetic de- 
flection amplifier and this character is written by electrostatic deflection. This 
amplifier also draws the vectors. The use of both electromagnetic and electro- 
static deflection is a unique method developed for this system. 

In addition to the cathode ray tube displays the consoles have event displays 
which are lamps driven by either the PCM stations and the computers via the C CIA. 

The consoles have on them a Computer Address Matrix keyboard which is 
used to control the high speed printer associated with each display and to trans- 
mit summary messages to the Manned Spacecraft Center in Houston. On all but 
one of the consoles there are command keyboards which are used to send com- 
mands to the spacecrafts . 

There is an intercom panel for each Flight Controller position. This inter- 
com gives the Flight Controller complete communication with the other locations 
on a station and to the spacecraft and other stations . 
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The consoles in a system are: 

The Command Communicator at which the Chief Flight Controller is 
stationed. 

The Lunar Excursion Module (LEM)/SIVB System Console. 

The Lunar Excursion Module (LEM) System Console. 

Two Command Systems Monitor (CSM) Consoles. 

The Aeromedical Console, which two doctors staff, monitors the biomed- 
ical data of the Astronauts by use of a cardioscope and one CRT display. 

The Flight Dynamics Officer’s Console is located on board the three track- 
ing ships used for Apollo only. This console is used primarily to monitor and 
control orbital insertion. 

There will also be a Maintenance and Operations (M&O) Console which is 
used to monitor the station systems. This console has no CRT displays. On 
non-flight control sites the M&O console will be the location of the Station Con- 
troller during missions. 
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l dcil-DATA CALL-UP SYSTEM FOR<yVPOLLO G 

L Charles E. Trevathan^ 


Mr. Trevathan is the System Design Group Leader of 
the Manned Flight Systems Engineering Section 
(MFOD) . Formerly with the Westinghouse Electric 
Company, he was a senior engineer responsible for 
design and development of digital communications and 
computing equipment. He joined Goddard in May 1965. 


Tracking sites at Guaymas, Mexico; Carnarvon, Australia; Ascension Is- 
land and Canary Island along with three Instrumentation Ships will form a unique 
group of facilities in the Manned Space Flight Network (MSFN) . 

Support of Apollo Missions by all MSFN sites must continue even when ad- 
verse conditions in communications with Mission Control Center at Houston 
(MCC-H) exist. Lack of ultra-reliable communications between MCC-H and 
these seven stations requires that they be equipped to accomodate teams of 
Apollo Flight Controllers. These teams will have the tasks of evaluating telem- 
etry data received from three space vehicles, making relevant decisions, and 
initiating the transmission of appropriate commands to the spacecrafts. As de- 
scribed in previous Data Topics articles, nineteen MSFN sites are implemented 
with a Command (CMD) Computer and a Telemetry (TLM) Computer which oper- 
ate in conjunction with three Pulse Code Modulation (PCM) Decommutation Sta- 
tions and the Unified S-Band System. However, to provide the Flight Control 
capability the seven facilities mentioned here contain a large quantity of addi- 
tional display type hardware. Each station is equipped with up to seven flight con- 
trol consoles, seven high speed printers, four analog strip recorders (8 chan- 
nels each), and six digital clocks for display of spacecraft time. Located on 
each console are spacecraft event indicators and command and data request 
keyboards containing push button indicator switches which afford Flight Con- 
trollers the means of initiating commands and requesting display of various 
data. These display subsystems and push button switches on the keyboards are 
interconnected with the TLM and CMD Computers by means of a Console Com- 
puter Interface Adapter (CCIA) . 

Contained in the CCIA subsystem are two Univac 1218 Computers and a 
Multiplexer (MUX), which is composed of two identical sections. Each MUX 
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section contains a switch position scanner, a data distributor, hundreds of indi- 
cator and clock element drivers, and sixteen digital to analog converters. Also 
included in the MUX cabinet is the buffer and translating circuitry required by 
seven high speed printers. All logical functions of the CCIA are accomplished 
by the sequential operation of a program stored in the 1218 computers. Each 
of the two computers is connected to one section of the MUX and this combina- 
tion services one half of the consoles, recorders, and clocks. Communications 
between the CCIA and the CMD and TLM computers is established by a straight 
forward intercomputer mode of operation controlled and timed by the 1218 oper- 
ational program. Other logical tasks of the 1218 are to accept continuous data 
from the MUX identifying the state of several hundred push button switches, de- 
tect a change in any switch 1 state , and determine the legality of switch operation. 
If the actuation is legitimate a 30 bit code identifying console, keyboard, and 
switch type is transferred to either the CMD or TLM computer as appropriate. 
The 1218 program also operates to accept telemetry data and command status 
from the TLM and CMD computers, perform some processing and distribute 
the data through the MUX to the various display devices. The processing men- 
tioned includes such operations as converting binary coded decimal time codes 
to straight decimal and addressing or labeling all through-put data to facilitate 
easy distribution by the Multiplexer. 

Suggested by the use of two 1218 computers and two identical MUX sections 
is a redundant system organization. This dual configuration yields a Console 
Computer Interface Adapter that can tolerate any "worst case" failure and con- 
tinue mission support with at least half the Flight Controllers display hardware 
and keyboards operational. In the event of such failure, the overall system 
functional capability would not be seriously impaired since keyboard overlays 
and switch selection would signal the computer program to redefine console 
identity and therefore continue with the high priority operations. By versatility 
gained with usage of computers in the CCIA, malfunction of either the CMD or 
TLM computer systems can also be tolerated. All four computers are pro- 
grammed to automatically redefine the data flow configuration as appropriate in 
event of failure. Consequently, multiple failures in the overall system could 
be experienced and yet mission support would be maintained with only a degra- 
dation in capability. 
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APOLLO PCM DECOMMUTATION SYSTEM 

William A. Dentel 


Mr. Dentel is the Technical Officer for the Apollo 
PCM Decommutation System. Prior to joining God- 
dard in March 1964, he was project engineer on a 
dual channel telemetry receiver at Vitro Electronics. 


The Pulse Code Modulation (PCM) system being installed at this time 
throughout the Manned Space Flight Network is one of the latest types to be de- 
veloped in the PCM field which in itself has been growing and advancing due to 
the industries' response to the users’ requirements. 

The PCM decommutation system for the Apollo Tracking site was designed 
and is being built by Dynatronics, Inc. , at Orlando, Florida. The system is 
designed to fulfill requirements and specifications which were written at God- 
dard. Three identical PCM decommutation systems are being installed at each 
new Apollo tracking site. 

The PCM system is an important link in the information transfer chain from 
our astronauts in the spacecraft and the Flight control team on the ground. The 
system serves as the interface between the RF receiving system and the Display 
System as well as the Data Processing Systems. 

The purpose of the PCM Decommutation system is to, first, reconstruct 
the incoming serial data, second, get into synchronization with the spacecraft 's 
commutation equipment and third, to distribute selected data or measurements 
to the proper output for further processing or display. 

The system employs a core memory of 4096 x 36 bit words which is capable 
of storing the decommutation and data routing information for ten different PCM 
formats, any one of which can be selected by a front panel control or at a remote 
location. 

The incoming serial data is processed in one of the system's two signal 
conditioners whose function is to obtain bit synchronization, make a bit by bit 
decision on the incoming data in the presence of signal perturbations such as 
noise and jitter and then reconstruct the data in the form required by the 
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decommutator. The decommutator receives this reconstructed data and begins 
a searching process to obtain synchronization with the incoming data. Synchro- 
nization is obtained by the decommutator's "looking" for a repetitive and fixed 
bit configuration or pattern. The correct pattern is stored in the PCM system’s 
memory and is continually compared with the incoming data until a matching 
pattern is found in the incoming spacecraft data at which time the decommutator 
changes to another mode of operation in which it checks that this is the correct 
pattern and is repetitive. When the check made has been completed and the 
pattern has been confirmed then the system goes to the lock mode at which time 
the PCM decommutation system on the ground is in synchronization with the 
spacecraft commutator. At this time, the incoming data is further processed 
by converting the serial data or "bit stream" into parallel data or "words". A 
word in the Apollo PCM format contains eight bits and the serial data is con- 
verted to "words" eight bits long. 

Data is further processed for various output devices. Two computer buffers 
in the PCM station provide parallel data for the DCS and telemetry 642 B com- 
puters. The two buffers are independent and any data in the PCM bit stream 
may be routed into either or both buffers for transfer to the computers. The 
data is further processed by the computers for display on the consoles and trans- 
mission to MCC-H. Each PCM system is wired for 127 digital to analog con- 
verters to provide analog information to the various systems on site. Each 
PCM station also contains 127 binary stores for the display of single bit informa- 
tion. This data is available in the form of relay closures to drive light displays 
on the display consoles. The PCM system is designed so that any bit in the 
PCM bit stream may be routed to any one of the 127 binary stores. 

The memory of the PCM system, which controls the input format and the 
distribution and routing of data, may be loaded manually from the panel by a 
paper tape reader included in the system or from the 642 B computer. The 
memory has a "cycle stealing" capability which permits the memory program 
to be up-dated in real time. This feature will provide the capability of closed 
loop data selection routing by the 642 B computer. 

The PCM system has the capability to perform (without the use of additional 
equipment) diagonistic self test routines for the purpose of maintaining the 
equipment. This self test capability has also proven to be of great value as a 
means of checking the interfaces between the PCM system and the Display con- 
soles without the necessity of utilizing other equipments. 

Each site is also receiving a stored program simulator which has the capa- 
bility of completely exercising the PCM system. 
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% APOLLO DIGITAL COMMAND SYSTEM - 


C? Carl B. Knox ( 


Mr. Knox is with the Systems Section of the Manned 
Flight Engineering Branch. He received his BS in 
Electrical Engineering at the University of Denver 
in 1953 and joined NASA in 1963. Previous to his 
Goddard employment, Mr. Knox worked for seven 
years at the Naval Security Engineering Facility in 
digital data transmission systems. 


The ground stations in the Manned Space Flight Network (MSFN) will have 
the capability of sending commands to orbiting spacecraft from computerized 
command systems. 

The purpose of the Apollo Digital Command System (DCS) is to provide a 
means for communicating with and controlling the spacecraft's equipment from 
the ground. Some commands are identified before the launch, others are devel- 
oped by the computing complex at the Mission Control Center in Houston (MCC- 
H) during the mission. 

The commands identified before the launch are the type that are to be exe- 
cuted at selected intervals during the mission. One of these commands may be 
sent several times from one or more ground stations. For example, a command 
requesting a tape playback of spacecraft recorded data may be sent by all sta- 
tions once or twice during a mission. 

Other commands developed during the mission by the MCC computers 
would ordinarily be sent only once by one station. However, if the transmission 
were not successfully accomplished by the selected station, it would be retrans- 
mitted by another station later during the mission. An example would be the 
correct time for the spacecraft computer. The time of the spacecraft computer 
is telemetered to the ground stations. If this parameter does not agree with the 
indicated ground time a command will be sent to the spacecraft computer that 
will update the timing system with the correct time. 

Commands are generated at the MCC in Houston then transmitted to the 
MSFN stations around the world for retransmission to the spacecraft. The 
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ground communication circuits and the RF communication circuits will have 
periods of low signal and high noise conditions that may result in the misin- 
terpretation of some data bits in the command words. 

All transmissions, ground to ground and ground to spacecraft, employ 
coding techniques to maintain a probability of 1 x 10 that the spacecraft will 
not accept a wrong command. 

The MCC computer transmission to the MSFN remote site computers will 
employ a data format that includes data bits and error detection bits. There 
will be a sufficient number of error detection bits in each frame of data to pro- 
vide the protection noted above, 1 x 10“ 9 . 

When the data is transmitted to the spacecraft via the RF link, a different 
technique is employed that has been used successfully in the Gemini program. 
First, each data bit is encoded into five sub-bits. If any five sub-bit pattern is 
not decoded properly by the spacecraft, the entire message is rejected. Sec- 
ondly, the first three bits of each word are employed as a vehicle address and 
the second three bits (number 4, 5, and 6) are used as a system address (to 
identify a particular spacecraft system, i.e. timing, computer, event control, 
etc.) A different sub-bit code is used for the vehicle address bits than that used 
for the remaining bits to enhance the probability of rejecting a non-valid com- 
mand word. 

There will be two general operational modes of the command system de- 
pending on the site configuration. 

Mode 1: Used at sites with flight controllers. The command is generated 
at Houston, transmitted to the site via high speed data modems where it 
is received, validated, and stored by the command data processor (Univac 
642B) . At the selected time, a flight controller at the remote site selects 
the command for transmission and the command is sent to the spacecraft. 

Mode 2: Used at sites without flight controllers or consoles. The command 
is generated at Houston, transmitted to the site, validated and stored by the 
command data processor as described in Mode 1 . At the selected time , a 
flight controller at Houston sends an execute command to the remote site 
and the command is then sent to the spacecraft. 

The commands will be sent to the spacecraft via one of two links , the Uni- 
fied S-Band (USB) equipment at 2106.4 or 2108.8 MC, or the UHF equipment at 
408 to 450 MC. The UHF equipment will be used for the prime link in the early 
phases of the program during the evaluation of the USB equipment. The USB 
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equipment will be the only mode of transmission during the lunar phases of the 
program. 

The command information to and from the command data processor is com- 
posed of a series of ONES and ZEROES at D. C. voltage levels. This information 
is transformed by the up data buffer to an audio PSK signal that modulates the 
RF carrier for transmission to the spacecraft. The PSK signal is composed of 
a 1 KC sync signal and a 2 KC data signal that are added linearly and referred 
to as a 3 KC composite signal. Sub data bits (the result of sub-bit encoding, 5 
for 1) are transmitted to the spacecraft at a 1 KBS rate. A ONE permits the 2 
KC signal to cross the zero axis in the positive direction in phase with the 1 KC 
sync signal. A ZERO causes the 2 KC signal to be shifted 180° so that it crosses 
the zero axis in the negative direction as the 1 KC sync signal goes positive. In 
the spacecraft, the composite signal is separated into its two component signals. 
The 1 KC signal is then used to control a phase lock demodulator circuit that 
extracts the binary data from the 2 KC data signal. 

A constant check on the effectiveness of the ground equipment is maintained 
by sampling the RF signal with verification receivers located near the trans- 
mitters. The output of the verification receivers is returned to the command 
data processor via the up data buffer. Valid command reception by the space- 
craft is verified by the telemetry downlink which is also returned to the com- 
mand data processor via the PCM decommutator equipment. In the event of 
ground equipment failure or spacecraft rejection of a valid command, the status 
information is presented to the local operators on a high speed printer. A com- 
mand summary message is also transmitted to the MCC in Houston. This mes- 
sage itemizes the time of each command transmission, describes the command, 
and indicates the spacecraft response to the command. 

One goal of the design and implementation of the Apollo Digital Command 
System was to provide for all known requirements of the Apollo program, plus 
the flexibility to satisfy any future requirements. Utilizing a general purpose 
computer as the main component in the command system will provide this flex- 
ibility with all the reliability obtainable by other special purpose devices of 
comparable complexity. The present system should prove adequate for the 
Apollo program and many future programs that require MSFN support. 
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Much has been written about the hardware to be used for Apollo mission 
support on the Manned Space Flight Network (MSFN) . This article concerns it- 
self with the software necessary to integrate hardware subsystems into a unique 
tool for mission control. 

The primary functions of computers on the MSFN in the past has been to 
display data for flight control purposes at the remote site, and transmit data to 
a central point, Mission Control Center in Houston. These functions have been 
perpetuated for Project Apollo, and an additional basic function has also been 
assigned to the digital computer on the Network. This added function is the con- 
trol of the Digital Command Process. In Project Gemini, digital commanding 
was carried out by a "black box;" this function will now be implemented by a 
computer. 

To accomplish these two basic tasks each site has been equipped with two 
UNIVAC M 642-B computers. Depending upon the type of peripheral equipment 
associated with the computers at the sites, a number of different computer pro- 
grams will be required. Two basic types of remote sites will be configured for 
Apollo mission support: one will possess full local control capability (flight con 
trol consoles, display system, etc.) and the other will be used in a slaved or 
"remoted" fashion from Mission Control Center in Houston. Although many pro 
grams will be written, a description of the highest level program for both 
"Telemetry /Display" and "Command" will provide the complete picture. 
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TELEMETRY/DISPLAY 


In general, the Telemetry /Display program will extract certain sets of 
parameters from raw telemetry input, perform some processing upon them, 
and present the group of parameters to a Flight Controller. The input to the 
program consists of up to three separate "vehicle-oriented" telemetry streams; 
a total of 174.4 kilobits per second. It is the selection of parameters from these 
input streams in real-time and the presentation of them in a suitable format 
that occupies the Telemetry /Display program. On an Apollo Flight Control Site 
there are a number of consoles having manual entry devices which may be used 
to signal the computer by means of an interrupt. Typically, the Telemetry/ 
Display program will respond to the depression of pushbutton in the following 
way: 

1 . The interrupt status word will be analyzed to determine the meaning of 
the request. 

2 . The proper parameters associated with the request will be selected from 
the input streams. 

3. The raw telemetry "bit count" will be converted to meaningful engineer- 
ing units . 

4. The present value of the parameters will be compared with preset limits. 

5. The names of the parameter requested together with their present values, 
plus a visual indication of "out of limits" conditions will be displayed on 

a Cathode Ray Tube. 

In addition to performing the monitoring function of telemetry parameters 
explained above, the next most basic function of the Telemetry /Display pro- 
gram, is the transmission of data on 2.4 Kilobits/Second (KBS) data lines to 
Houston. As stated above this input to the program may range up to 174.4 KBS. 
Since there are only 2. 4 KBS available on the output side of the program it is 
obvious that some judicious editing must be done by the computer before data 
transmission may take place. One of the ground rules for data selection is that 
not all data are required for flight control simultaneously; that is, data require- 
ments are dependent upon the phase of the mission. Therefore, the Telemetry/ 
Display program will contain eight different formats which are selectable in 
real-time. Thus, as the mission phase changes and data requirements are 
modified, the telemetry program will be able to meet these changes in a flexible 
manner. 
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The Telemetry /Display program will also possess the same "Low Speed 
Summary" capability that exists in the Gemini telemetry programs. It will be 
possible to load last-minute engineering unit changes, calibration curve changes, 
and limits, into the program from the high speed input (2. 4 KBS) data lines. 

This feature will ease the logistical problem normally associated with last 
minute changes to an operational program. 

Other methods of presenting data to flight control personnel will be imple- 
mented by the Telemetry /Display program. Four chart recorders each dis- 
playing 8 channels of analog information will be driven by the program. Each 
recorder will possess a six -position switch called "format control switch." 

When the position of the switch changes, the program will respond by selection 
of a different set of parameters to be transmitted to that particular recorder. 

Six digital clocks will be driven by the Telemetry /Display program. The six 
time words will be extracted from downlinked Telemetry data and transmitted 
to the clocks via the Console/Computer Interface Adapter. 


COMMAND PROGRAM 

The Command Program will be able to operate in two basic modes. When a 
command or load is selected at the remote site for uplinking, the site is oper- 
ating in Mode 1. If the command process had been initiated from Houston, the 
site is said to be operating in Mode 2. Whether a site is operating in Mode 1 
or Mode 2, the internal logic of the program remains identical for all classes. 
Prior to a mission, the Command Program will be assembled to contain the 
necessary Real Time Commands (RTC) and space will be provided in the pro- 
gram for Vehicle Computer Loads. This means that specific "loads" of com- 
puter data will be accepted by the Command Program in real time. Once a re- 
quest for the uplink of a Real Time Command or Load has been initiated, the 
Command Program will react in the following way: 

1. The Command data is formatted into the proper sub-bit encoding per the 
vehicle being commanded. 

2. A data path through the requested uplink system is established by the 
Command Program. 

3. The Command data is then transmitted to the Updata Buffer following the 
ground rules required by the hardware. 

4. During the period of transmission of data through the uplink system, the 
verification receivers decode the computer output and transmit the in- 
formation back to the Command Program. The program can compare 
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what it transmitted to what it received; and in the event of an error , can 
establish a new data path by switching alternate modules of equipment on 
line. This procedure is known as ground-loop verification. 

5. When the program senses that the last piece of data has been transmitted, 
i.e. , a complete command has been sent, it will go into a spacecraft 
validation loop. This simply means that the Command Program will 
attempt to verify that the spacecraft has accepted or rejected the trans- 
mitted command. The program does this by referring to the downlinked 
telemetry data which contains the acceptance or rejection information. 

6. Finally, the Command Program performs the necessary bookkeeping 
function to inform flight control personnel about the status of the com- 
manded vehicle. 

The above steps constitute the essentials of the Command Program from the 
standpoint of internal data flow. If the site had been operating in "Mode 1," the 
request to uplink a command would have come from a local Flight Control Con- 
sole (The Command Keyboard). Thus, it's evident that the Command Program 
will require the same type of keyboard interrupt processing as the Telemetry/ 
Display program. If the site had been operating in "Mode 2," it would mean 
that the request to uplink the "Load" or RTC had come directly from Houston via 
high speed data lines. 

During the actual commanding process, the Command Program will record 
the highlights and milestones of the procedure; and the Flight Controller will be 
able to request a complete history of the commanding activity to be printed at 
his console. This history would contain information such as the name of each 
RTC transmitted, the number of uplink attempts, and a report if errors had 
been encountered. The program will also keep Maintenance and Operation 
(M&O) personnel informed of the status of the commanding process by means 
of printouts on high speed printers and illuminated indicators. For example, if 
in step 4 of the command uplink procedure, the program had detected a mal- 
function in ground equipment, it would inform site M&O personnel for corrective 
action. 

It is impossible in the space allowed to explain every facet of all remote 
site programs. But I believe enough has been said to show that when flexible 
Software is merged with powerful Hardware, the result is a new level of so- 
phisticated mission support on the MSFN. 
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The major data systems installed in the Manned Space Flight Network for 
Apollo support have been described in the previous articles. The test plan for 
the check-out and qualification of these sophisticated systems are described in 
this article. 

The Apollo engineering test program is divided into five major categories: 

• Factory Unit Test 

• On-Site Unit Test 

• Special Test 

• Systems Integration Test 

• Dynamic Integration Test 

The purpose of this group of tests is to satisfactorily demonstrate that the 
Apollo systems have been properly designed and interfaced to support the Apollo 
missions. The tests are designed to progress from the lowest building block to 
the demonstration of the over-all site performance. 

Factory Unit Tests— Upon completion of the manufacturing process on each 
system, acceptance tests are performed at the manufacturer's plant prior to 
shipment of the units to the remote sites. The factory unit tests are designed to 
demonstrate each system's capability of meeting the requirements of the engi- 
neering specification. These tests are prepared by the manufacturer and sub- 
mitted to NASA for approval. Each equipment which is shipped from the manu- 
facturer's plant must pass the test satisfactorily. 

On Site Unit Tests — After installation of the various systems on site, unit 
tests are performed to insure that the equipment has been correctly installed 
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and aligned. In most instances these tests are abbreviated versions of the fac- 
tory unit tests. The purpose of these tests is to demonstrate the equipment's 
ability to perform to specification after shipment to the remote site. 

Systems Integration Tests — When on-site unit tests have been completed on 
the various systems, integration tests are necessary to insure that they have 
been properly interfaced. The site integration tests are designed to check each 
of the interfaces between the various systems. The systems integration tests 
are divided into the following categories: 

• Computer Display System 

• PCM System 

• Command System 

• Telemetry RF 

• Recorders 

• Timing 

• Voice 

• Acquisition 

• Site Intercommunications 

• Up-Link Tests 

• Down-Link Tests 

The system integration tests have been designed to demonstrate the equip- 
ment's capability to meet engineering specifications rather than mission require- 
ments. The various systems have been designed to exceed mission require- 
ments, therefore, it is desirable to determine the overall capability of the site 
not only to support present missions but also to support requirements levied by 
future missions. Tests which are performed as part of the unit test are not 
repeated during this phase. The objectives of these tests are to demonstrate 
the capability of the various systems operating together. The equipment is 
tested under actual interface condition with artificial interface connections 
held to an absolute minimum. To insure that a minimum amount of time is re- 
quired to perform the site integration tests, procedures have been designed to 
make maximum utilization of the on-site computers as test tools for checking 
the various systems. The majority of the interface tests have been automated 
to permit a larger number of tests to be performed with a minimum amount of 
effort by on-site personnel. The computers are utilized in the test to act as a 
stimulus for the various systems as well as analyzing the test results in real 
time. 

Dynamic Site Integration Tests — The dynamic site integration tests will 
utilize an instrumented aircraft to simulate the Apollo spacecraft. The object 
of this test is to insure that dynamic incompatibilities do not exist between the 
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various systems. The dynamic tests are divided into the following categories: 

• Tracking Systems 

• Voice Communications 

• Down- Link Data 

• Up-Link Data 

During the performance of these tests the antennas track the instrumented 
aircraft to determine acquisition, tracking, and slaving capabilities. Up-link 
and down-link data tests insure that no RFI problems are encountered. 

Special Tests — Several special tests have been prepared to further check 
the network. At present these fall into two categories: 

• Site Acceptability Evaluation Program 

• Site Operational Program Test 

Site Acceptability Evaluation Program — The purpose of the Site Accepta- 
bility Evaluation Program (SAEP) test is to exercise the data processing system 
to insure that it will operate satisfactorily with all interface equipments operat- 
ing at their maximum required rate. The test will check the computer and peri- 
pheral equipment operating at the maximum input and output data transfer rates 
and check queing functions between the computer and peripheral equipments. 

Site Operational Program Test — Since the operational programs for the 
642 B computers will not be available during site evaluation tests, a procedure 
is being prepared to repeat certain tests of the various systems after the opera- 
tional program is available. During this test the operational program will be 
loaded into the 642 B and simulated data will be provided by pre-recorded tapes. 
This test will not simulate an actual mission but rather will provide a means for 
checking the computer and peripheral equipments to determine their satisfactory 
performance when operating with the operational program. 

By the performance of these tests , MFOD will establish a high level of confi- 
dence that the Manned Space Flight Network is capable of supporting the Apollo 
missions. The successful completion of these tests will conclude one phase of 
the Apollo design and implementation efforts which GSFC has expended over the 
past three years in the development of the Apollo network. It represents the 
efforts of the many personnel assigned to the Apollo program at GSFC to com- 
plete another vital link in the landing of a man on the moon and his safe return. 
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